Oracle GoldenGate Interview Questions

 

Oracle Goldengate Interview Questions and Answers

Q1) What type of Topology does Goldengate support?

Ans: GoldenGate supports the following topologies. More details can be found

• Unidirectional
• Bidirectional
• Peer-to-peer
• Broadcast
• Consolidation
• Cascading

Q2) What are the main components of the Goldengate replication?

Ans: The replication configuration consists of the following processes.

• Manager
• Extract
• Pump
• Replicate

Q3) What database does GoldenGate support for replication?

Ans:

• Oracle Database

TimesTen

• MySQL

IBM DB2

Microsoft SQL Server

Informix

• Teradata

Sybase

Enscribe

SQL/MX

Q4) What transaction types does Goldengate support for Replication?

Ans: Goldengate supports both DML and DDL Replication from the source to target.

Q5) What are the supplemental logging pre-requisites?

Ans:

The following supplemental logging is required.

• Database supplemental logging
• Object-level logging

Q6) Why is Supplemental logging required for Replication?

Ans: When a transaction is committed on the source database, only new data is written to the redo log. However for Oracle to apply these transactions on the destination database, the before image key values are required to identify the affected rows. This data is also placed in the trail file and used to identify the rows on the destination, using the key-value the transactions are executed against them.

Q7) List important considerations for bi-directional replication?

Ans: The customer should consider the following points in an active-active replication environment.

• Primary Key: Helps to identify conflicts and resolve them.
• Sequences: Are not supported. The workaround is used to use odd/even, range, or concatenate sequences.
• Triggers: These should be disabled or suppressed to avoid using uniqueness issue
• Data Looping: This can easily be avoided using OGG itself
• LAG: This should be minimized. If a customer says that there will not be any LAG due to network or huge load, then we don’t need to deploy CRDs. But this is not the case always as there would be some LAG and these can cause Conflicts.
• CDR (Conflict Detection & Resolution): OGG has built-in CDRs for all kind of DMLs that can be used to detect and resolve them.
• Packaged Application: These are not supported as it may contain data types that are not supported by OGG or it might not allow the application modification to work with OGG.

Q8) What is the data pump process in Goldengate?

Ans:

The Data Pump (not to be confused with the Oracle Export Import Data Pump) is an optional secondary Extract group that is created on the source system. When Data Pump is not used, the Extract process writes to a remote trail that is located on the target system using TCP/IP. When Data Pump is configured, the Extract process writes to a local trail and from here Data Pump will read the trail and write the data over the network to the remote trail located on the target system.

The advantages of this are it protects against a network failure as in the absence of a storage device on the local system, the Extract process writes data into memory before the same is sent over the network. Any failures in the network could then cause the Extract process to abort (abend). Also, if we are doing any complex data transformation or filtering, the same can be performed by the Data Pump. It will also be useful when we are consolidating data from several sources into one central target where the data pump on each individual source system can write to one common trail file on the target.

Q9) Where can the filtering of data for a column be configured?

Ans: Filtering of the columns of a table can be set at the Extract, Pump, or Replicat level.

Inclined to build a profession as Oracle Goldengate Training? 
Then here is the blog post on, explore Oracle GoldenGate Training

Q10) Is it a requirement to configure a PUMP extract process in OGG replication?

Ans: A PUMP extract is an option, but it is highly recommended to use this to safeguard against network failures. Normally it is configured when you are setting up OGG replication across the network.

Q11) What are the differences between the Classic and integrated Capture?

Ans:       

Classic Capture:

• The Classic Capture mode is the traditional Extract process that accesses the database redo logs (optionally archive logs) to capture the DML changes occurring on the objects specified in the parameter files.
• At the OS level, the GoldenGate user must be a part of the same database group which owns the database redo logs.
• This capture mode is available for other RDBMS as well.
• There are some data types that are not supported in Classic Capture mode.
• Classic capture can’t read data from the compressed tables/tablespaces.

Integrated Capture (IC):

• In the Integrated Capture mode, GoldenGate works directly with the database log mining server to receive the data changes in the form of logical change records (LCRs).
• IC mode does not require any special setup for the databases using ASM, transparent data encryption, or Oracle RAC.
• This feature is only available for Oracle databases in Version 11.2.0.3 or higher.
•  It also supports various object types that were previously not supported by Classic Capture.
• This Capture mode supports extracting data from source databases using compression.
• Integrated Capture can be configured in an online or downstream mode.

Q12) List the minimum parameters that can be used to create the extract process?

Ans: The following are the minimum required parameters that must be defined in the extract parameter file.

• EXTRACT NAME
• USERID
• EXTTRAIL
• TABLE

Q13) What are macros?

Ans: Macro is an easier way to build your parameter file. Once a macro is written it can be called from different parameter files. Common parameters like username/password and other parameters can be included in these macros. A macro can either be another parameter file or a library.

Q14) What is the command-line utility in GoldenGate (or) what is ggsci?

Ans:

• Golden Gate Command Line Interface essential commands – GGSCI
• GGSCI   -- (Oracle) GoldenGate Software Command Interpreter

Q15) Where can macros be invoked?

Ans: The macros can be called from the following parameter files.

• Manager
• Extract
• Replicat
• Gobals

Q16) How is a macro defined?

Ans: A macro statement consists of the following.

• Name of the Macro
• Parameter list
• Macro body
• Sample: MACRO #macro_name PARAMS (#param1, #param2, …) BEGIN < macro_body > END;

Q17) What type of Encryption is supported in Goldengate?

Ans: Oracle Goldengate provides 3 types of Encryption.

• Data Encryption using Blowfish.
• Password Encryption.
• Network Encryption.

Q18) What are the different password encryption options available with OGG?

Ans: You can encrypt a password in OGG using

• Blowfish algorithm and
• Advanced Encryption Standard (AES) algorithm

Q19) Is there a way to check the syntax of the commands in the parameter file without running the GoldenGate process?

Ans: Yes, you can place the SHOWSYNTAX parameter in the parameter file and try starting. If there is any error, you will see it.

Q20) How can you increase the maximum size of the read operation into the buffer that holds the results of the reads from the transaction log?

Ans: If you are using the Classical Extract you may use the TRANSLOGOPTION ASMBUFSIZE parameter to control, the read size for ASM Databases.

Q21) What information can you expect when there us data in the discard file?

Ans: When data is discarded, the discard file can contain:

• Discard row details
• Database Errors
• Trail file number

Q22) What command can be used to switch writing the trail data to a new trail file?

Ans: You can use the following command to write the trail data to a new trail file.

SEND EXTRACT ext_name, ROLLOVER

Q23) How can you determine if the parameters for a process was recently changed?

Ans: Whenever a process is started, the parameters in the. prm file for the process is written to the process REPORT. You can look at the older process reports to view the parameters which were used to start up the process. By comparing the older and the current reports you can identify the changes in the parameters.

Q24) What happens if RVWR cannot write to disk?

Ans:

• It depends on the context where the write error occurs:
• If there’s a Guaranteed Restore Point, the database crashes to ensure the restore point guarantee is not voided.
• If there isn’t a Guaranteed Restore Point and it’s a primary database, the Flashback Mode will be automatically turned off for the database, which will have continued to operate normally.
• If there isn’t a Guaranteed Restore Point and it’s a standby database, the database will hang until the cause of the write failure is fixed.

Q25) How to list restore points in RMAN?

Ans: In RMAN you can use the LIST RESTORE POINT [ALL|restore_point_name] command. If you use a recovery catalog you can use the view RC_RESTORE_POINT in the recovery catalog repository, or command the V$RESTORE_POINT in the target database.

Q26) Can you see the progress of a FLASHBACK DATABASE operation?

Ans:

1. Yes, you can. During a FLASHBACK DATABASE operation, you can query V$SESSION_LONGOPS from another session to see the progress of the flashback.
2. The FLASHBACK DATABASE operation has two distinct phases: the actual flashback and the media recovery that happens afterward to bring the database to a consistent state.
3. While the actual flashback is running, you’ll see the following message in V$SESSION_LONGOPS, on Oracle 11gR2:
4. Flashback Database: Flashback Data Applied: 238 out of 282 Megabytes done
5. During the media recovery, the following messages will be seen:

• Media Recovery: Redo Applied: 263 out of 0 Megabytes done
• Media Recovery: Average Apply Rate: 1164 out of 0 KB/sec done
• Media Recovery: Last Applied Redo: 626540 out of 0 SCN+Time done
• Media Recovery: Elapsed Time: 232 out of 0 Seconds done
• Media Recovery: Active Time: 116 out of 0 Seconds done
• Media Recovery: Active Apply Rate: 1859 out of 0 KB/sec done
• Media Recovery: Maximum Apply Rate: 1859 out of 0 KB/sec done
• Media Recovery: Log Files: 15 out of 0 Files done
• Media Recovery: Apply Time per Log: 7 out of 0 Seconds done

Q27) How should I set the database to improve Flashback performance?

Ans: Oracle’s recommendations are:

• Use a fast file system for your flash recovery area, preferably without operating system file caching. It is recommended to use a file system that avoids operating system file caching, such as ASM.
• Configure enough disk spindles for the file system that will hold the flash recovery area. For large production databases, multiple disk spindles may be needed to support the required disk throughput for the database to write the flashback logs effectively.
• If the storage system used to hold the flash recovery area does not have non-volatile RAM, try to configure the file system on top of striped storage volumes, with a relatively small stripe size such as 128K. This will allow each write of the flashback logs to be spread across multiple spindles, improving performance
• For large, production databases, set the init.ora parameter LOG_BUFFER to be at least 8MB. This makes sure the database allocates maximum memory (typically 16MB) for writing flashback database logs.